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About this Guide 
About Qualys 


About this Guide 


Welcome to Qualys Container Runtime Security (CRS). CRS provides runtime behavior 
visibility & enforcement capabilities for running containers. We'll help you get started. 


About Qualys 


Qualys, Inc. (NASDAQ: QLYS) is a pioneer and leading provider of cloud-based security and 
compliance solutions. The Qualys Cloud Platform and its integrated apps help businesses 
simplify security operations and lower the cost of compliance by delivering critical 
security intelligence on demand and automating the full spectrum of auditing, 
compliance and protection for IT systems and web applications. 


Founded in 1999, Qualys has established strategic partnerships with leading managed 
service providers and consulting organizations including Accenture, BT, Cognizant 
Technology Solutions, Deutsche Telekom, Fujitsu, HCL, HP Enterprise, IBM, Infosys, NTT, 
Optiv, SecureWorks, Tata Communications, Verizon and Wipro. The company is also 
founding member of the Cloud Security Alliance (CSA). For more information, please visit 
www.qualys.com 


Qualys Support 


Qualys is committed to providing you with the most thorough support. Through online 
documentation, telephone help, and direct email support, Qualys ensures that your 
questions will be answered in the fastest time possible. We support you 7 days a week, 
24 hours a day. Access online support information at www.qualys.com/support/. 
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About Container Runtime Security 


Container Runtime Security (CRS) provides runtime behavior visibility & enforcement 
capabilities for running containers. This allows customers to address various use cases for 
running containers around security best practice enforcement, file access monitoring, 
network access control. 


CRS requires instrumentation of container images with the Qualys Container Runtime 
Instrumentation, which injects probes into the container image. Customers can configure 
instrumented images, containers with granular policies which govern container behavior, 
visibility. Based on these runtime enforcement policies - runtime events, telemetry can be 
viewed obtained from the backend via UI, API. 


CRS is currently supported for Linux OS based containers only. 


CRS Architecture 


The diagram below provides a recommended container security workflow leveraging 
Qualys Container Security (Scanning + Container Runtime Security). 
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CI Plugin Protected Containers 


Tags Image: Containers 


qualys_scan_target:<image_id> 


The workflow for Container Runtime Security starts with instrumentation of the target 
container image. Qualys provides a customer premise Instrumenter that can be leveraged 
in a customer environment to instrument application containers with Qualys’ security 
probes. It can be run locally in CLI mode or it can be provisioned as an always running 
microservice backend. 


Our instrumentation approach layers in an enhanced version of the glibc linux library 
which provides container behavior visibility and enforcement. Application containers 
spun up from instrumented application container images register with the Qualys Cloud 
Platform and obtain runtime policies. These runtime policies and the Qualys 
instrumentation autonomously drive container behavior visibility & enforcement. 
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CRS Instrumentation 


Protecting containers with Qualys CRS requires instrumentation of a container image with 
the Qualys Instrumentation. You have 2 options for instrumenting container images - 
instrument images on your local host using CLI mode, or run our Instrumenter service in 
the backend to instrument images that have been scanned by a registry scan job. 


Instrumentation using CLI mode - This approach is used for instrumenting individual 
images on your local host. You'll run the instrumenter.sh script with CLI mode enabled 
(CLI mode is enabled by default) and identify the image to instrument. The image must be 
present locally where you're running the CLI command. You can optionally specify the 
runtime policy to apply to the instrumented image. When you instrument an image using 
this method, we'll immediately add in our solution and create the instrumented image 
(appended with -layered) at the same location. One command will instrument one image 
only, and then it will exit as soon as instrumentation is done. 


Instrumentation using the Instrumenter service - This approach is used for 
instrumenting images that have been scanned by a registry scan job (registry sensor). The 
nstrumenter service is a lightweight microservice that runs in the customer premise. The 
nstrumenter service is packaged and distributed to customers as a container image. This 
instrumenter container is meant to be run on a container host. It requires connectivity 
back to the Qualys backend. The backend federates instrumentation requests to this 
microservice. Once an image is submitted for instrumentation (via UI, API), the 
instrumenter inspects the image, injects the Qualys instrumentation, and provides as 
output a new “instrumented” version of the image. This new image is then uploaded back 
to the destination container registry with "-layered" appended to the tag. This worktlow is 
coupled tightly with a registry. 


Requirements 
The Instrumenter service requires the following: 


1) Docker engine/server and a DOCKER HOST socket connection 

2) Docker V2 registry: 

Public registries: Docker Hub 

Private registries: v2-private registry: JFrog Artifactory (secure: auth + https) 


Compatibility 


- The Instrumenter service is able to request Qualys Container Security user credentials 
from Vault secret engine types: kv-v1 and kv-v2. Although supported, it is not 
recommended to pass credentials in plain text, unencrypted to the Instrumenter service. 
More details further in this document. 


- The Instrumenter container requires a Docker engine greater than 1.12. 
Limitations 
Please note the following limitations: 


- Only certain container images are supported for instrumentation (see details below) 
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- Multiple Instrumenters per subscription are supported. Currently there is no visibility of 
Instrumenters via the UI or API. 


- One Instrumenter service per docker engine/server host is supported 


- Instrumentation jobs are delivered to any authenticated Instrumenter when using the 
Instrumenter service to instrument images 


Images supported for instrumentation 


Instrumentation is supported for container images with certain glibc versions. The table 
below shows the top images supported per operating system. 


Want to know if your image is supported? Use the following script to check: 
https://github.com/Qualys/qualys. crs instrumenter/blob/master/check if image instru 
mentable.sh 


OS version libc/glibc version Docker Name: Tag Docker Image SHA (Repo Digest) 


Alpine 
3.13.5 


musl-1.2.2-r0 alpine:3.13.5 pine@sha256:1d30d1ba3cb9096206 
€9b29491fbd56997979d54376f23f014 


8b5c5cd8b462 


pine@sha256:de25c7fc6c4f3a27c7f0 
2dff454e4671823a34d88abd533f210 
48d527e0fbb 


alpine@sha256:c0e9560cda118f9ec63 
ddefb4a173a2b2a0347082d7dff7dc14 
272e7841a5b5a 


AN © 


3.12.7 musl-1.1.24-r10 alpine:3.12.7 


on © 


3.12.1 musl-1.1.24-r9.apk alpine:3.12.1 


musl-1.1.24-r3 alpine:3.11 alpine@sha256:6cf3d8abc08cf3792d5 
90152d7a4628ec827621f55b1d315038 
3f 


5f39335d6eb 


3.10.5 musl-1.1.22-r3 alpine:3.10 alpine@sha256:f0e9534a598e5013209 
57059cb2a23774b484072e37c7b2cf7e 
9 


5b241f019e35 


pine@sha256:7746df395af22f04212 
cd25a92c1d6dbc5a06a0ca9579a229ef 
43008d4d1302a 


alpine:3.9.2 alpine@sha256:644fcb1a676b5165371 
437feaa922943aaf7afcfasbfee4472f68 
60aad1ef2a0 


pine@sha256:414e0518bb9228d35e 
4cd5165567fb91d26c6a214e9c95899e 
1e056fcd349011 


3.9.4 musl-1.1.20-r4 alpine:3.9.4 


w 


3.9.2 musl-1.1.20-r3 


3.9 musl-1.1.20-r5 alpine:3.9 


w 


Amazon Linux 


2 glibc-2.26- 
33.amzn2.0.2.x86_64 


amazonlinux:2.0.20 
191217.0 


amazonlinux@sha256:58d05c596a29f 
2cfb81543dddd01ca5613bc33e2a65a5 
567dc875d50e7225f9c 
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OS version libc/glibc version Docker Name: Tag Docker Image SHA (Repo Digest) 
2 glibc-2.26- amazonlinux:2.0.20 amazonlinux@sha256:5aa0460abffaf 
33.amzn2.0.1.x86 64 191016.0 c6a76590f0070e1b243a93b7bbe7c803 
5f98c1dee2f9b46f44c 
Gentos 
8 glibc-2.28- centos:8.1.1911 centos@sha256:fe8d824220415eed54 
72.e18.x86 64 77b63addf40fb06c3b049404242b3198 
2106ac204f6700 
7 glibc-2.17- centos:7 centos@sha256:0f4ec88e21daf75124b 
323.e]7 9.x86 64 8a9e5ca03c37a5e937e0e108a255d890 
492430789b60e 
7 glibc-2.17- centos:centos7 centos@sha256:19a79828ca2e505eae 
307.e17.1.x86 64 eOff38c2f3fd9901f4826737295157cc52 
12b7a372cd2b 
7 glibc-2.17- centos:7.7.1908 centos@sha256:50752af5182c6cd551 
292.e]7.x86 64 8e3e91d48f7ff0cba93d5d760a67ac140 
e2d63c4dd9efc 
Debian 
10 2.28-10 debian:10 debian@sha256:e2fe52e17d649812bd 
dcac0/faf16f33542129a59b2c1c59b39 
a436754b7f146 
9 (stretch) glibc_2.24- debian:9.13 debian@sha256:26d14aa81aa59de744 
11+deb9u4 d6ec9509000341f3f8e0160d78f3659f1 
d25a2b252d28e 
9 (stretch) glibc_2.24- debian:9.4 debian@sha256:6ee341d1cf3da8e6ea 
11+deb9u3 059f8bc3af9940613c4287205cd71d7c 
6f9e1718fdcb9b 
9 (stretch) glibc_2.24- debian:9.1 debian@sha256:5fafd38cdee6c7e6b97 
11+deb9u1 356092b97389faa0aa069595f1c3cc33 
44428b5fd2339 
Ubuntu 
bionic- 2.27-3ubuntu1.3 ubuntu:bionic- ubuntu@sha256:fd25e706f3dea2a5ff7 
20201119 20201119 05dbc3353cf37f08307798f3e360a13e9 
385840f73fb3 
bionic- 2.27-3ubuntul.2 ubuntu:bionic- ubuntu@sha256:05a58ded9a2c79259 
20200807 20200807 8e8f4aa8ffe300318eac6f294bf4f49a7a 
bae7544918592 
18.04 elibcVersion:libc6_2.  ubuntu:18.04 ubuntu@sha256:7bd7a9ca99f868bf69 
27-3ubuntul.4 C4b6212f64f2af8e243f97ba13abb3e64 
1e03a7ceb59e8 
Google Distroless Images 
gcrio/distro N/A gcrio/distroless/jav — gcr.io/distroless/java@sha256:97c7ea 
less/java:11 a:11 e86c65819664fcb7f36e8dee54bbbbcO 


9c2cb6b448cbee06e1b42df81b 
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OS version libc/glibc version Docker Name: Tag Docker Image SHA (Repo Digest) 
gcr.io/distro N/A gcrio/distroless/jav ger.io/distroless/java@sha256:34c359 
less/java:8 a:8 8d83f0dba27820323044ebe79e63ad4f 

137b405676da75a3905a408adf 
gcrio/distro N/A gcrio/distroless/jav | gcr.io/distroless/java@sha256:966248 
less/java:8- a:8-debug 918d67e17ad371537a7b76c70c2e54ba 
debug 64681b174003692e3a0200e9a5 


In-Container Instrumentation 


The Qualys instrumentation consists of glibc based hooks to intercept system calls being 
made. CRS policies, configurations for in-container instrumentation are obtained from the 
Qualys Cloud backend. The CRS policies are translated into syscall firewall rules and the 
in-container instrumentation provides visibility into and enforces container behavior. CRS 
policy events and CRS telemetry is regularly sent back to the Qualys backend where it can 
be viewed by API, UI. 


Qualys Cloud 
Platform 


User Application 
User 


Space 


@ Enhanced gnu C 
Daemon Library (glibc) 
Events 


x 

E System Call Interface Policy, 

$ Configuration 
Kernel updates 


Architecture dependent Space 
Kernel Code 


In-Container Qualys Instrumentation 


Hardware Platform 


: . (with Behavioral Policy) 
In-Container Qualys Instrumentation 


Qualys Backend 


The Qualys backend manages the end-to-end workflow of CRS. From instrumenting 
images to managing the policy workflow to viewing CRS telemetry and policy hits. 
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CRS Deployment Workflow 


Here's a look at the deployment workflow for Container Runtime Security. 


Step 1: Instrument container images with Qualys instrumentation 


You have 2 options for instrumenting images - you can instrument any image on your 
local host using CLI mode (see 13), or you can run our Instrumenter service in the backend 
to instrument images that have been scanned by a registry scan job (see 1b). Choose the 
approach you want to take and follow the steps. 


1a) Instrument image using CLI mode 


Instrument an image on your local host. We'll immediately add in our runtime security 
solution and create the instrumented image (appended with -layered) at the same 
location. One command will instrument one image only, and then it will exit as soon as 
the instrumentation is done. Tip - If you have a runtime policy ready to go, you can 
immediately apply the policy to the instrumented image when running the CLI command. 


Instrument images using CLI mode 


1b) Instrument image using the Instrumenter service 


To use the Instrumenter service, you'll need to complete the following steps: 


Build image, Push image to registry, and Scan with registry sensor 

You'll build the image and push it to the registry. Then scan each image you want to 
instrument with the registry sensor. This is required for using the Instrumenter service. 
Deploy the Instrumenter service in your environment 

The Instrumenter service will be used to pull down the unprotected image, package our 
solution into it, and then push it back to the registry as a protected image. 


Deploy the Instrumenter Service 


Instrument container image from the UI 


When using the Instrumenter service, you'll kick off instrumentation from the UI. Identify 
the image you want to instrument on the Images list, and choose the Instrument option. 
The UI sends an instrumentation job to the deployed Instrumenter. We'll package in our 
solution, and push the protected image back to the registry. Once you have the protected 
image, you can run the image in your runtime environment as a running container. 


Instrument images from the UI 


Step 2: Configure policies and instrumentation 


Create policies, and assign a policy to an instrumented image. You'll also want to set the 
policy enforcement level (determines whether policy rules are enforced) and select the log 
mode (determines which policy hits get logged). 


Configure and Apply Policies 


10 
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Set policy enforcement 
Apply policy to instrumented image 


Configure Instrumentation 


Step 3: Run container from instrumented image 


When ready, you can spawn containers from the instrumented image. The policy applied 
to the instrumented image gets enforced on the container and activities are logged as per 
the selected log mode. 


Run containers from instrumented image 


Step 4: View your events 


Runtime events will be listed on the Events tab. Here you can search events and drill-down 
into event details. 


View Your Events 


View event details on dashboard 


11. 
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Deploy the Instrumenter Service 


You can run the Instrumenter service using any of these options: 
Option 1: Run instrumenter using docker CLI based command 
Option 2: Run docker compose file 


Option 3: Run kubernetes instrumenter.yml 


Option 1: Run instrumenter using docker CLI based command 


This option lets you run the instrumenter in CLI mode (the default) for instrumenting 
images locally or in Daemon mode to use the instrumenter microservice to instrument 
images from the registry. You can run the instrumenter with or without a vault. 


Prerequisites 


- Request access to the Docker Hub private repo for qualys/crs-cli-instrumenter. To 
request access, reach out to Qualys Support from qualys.com/support and be sure to 
include your Docker Hub ID in your message. 


- Run docker login with the provided Docker Hub ID on the instance where you will run 
instrumenter.sh in CLI mode. 
Using CLI mode 


1) Pull the docker CLI files from github. You can download them from 
https://github.com/Qualys/qualys_crs_instrumenter 


2) Edit instrumenter.sh to configure specific details for proxy and vault usage. See File 
parameters for guidance on inputs. 


3) Run the docker CLI script. 


By default, the script will run in CLI mode and for this mode you must specify the 
endpoint and image. Policy ID is optional. Use this command to run the script: 


sh instrumenter.sh --endpoint 
<qualys username»:«qualys password>@<api gateway url»/crs/v1.2 
--image «image» [--policyid «policy id>] 


To use the instrumenter microservice to instrument images from the registry, you must 
run the script in Daemon mode. Specify --daemon-mode and specify the endpoint. In this 
case, you do not specify the image or policy. Use this command to run the script: 


sh instrumenter.sh --endpoint 
<qualys username>:<qualys password>@<api gateway url>/crs/vl.2 
--daemon-mode 
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Usage Examples 


Default Example - CLI mode: 


./instrumenter.sh --endpoint «endpoint» --image «image» [-- 
policyid «policy id>] 


Default Example - Daemon mode: 


./instrumenter.sh --endpoint «endpoint» --daemon-mode 


Vault Example - CLI mode: 


./instrumenter.sh --endpoint «endpoint» --vault-token «token» 
--vault-engine «engine version» [--vault-base64] --vault-path 
<vault-path> --vault-address «vault-address» --image «image» [-- 
policyid «policy id>] 


Vault Example - Daemon mode: 


./instrumenter.sh --endpoint «endpoint» --vault-token «token» 
--vault-engine «engine version» [--vault-base64] --vault-path 
<vault-path> --vault-address <vault-address> --daemon-mode 


Proxy Example - CLI mode: 


./instrumenter.sh --endpoint «endpoint» --proxy «proxy» --image 
«image» [--policyid «policy id>] 


Proxy Example - Daemon mode: 


./instrumenter.sh --endpoint «endpoint» --proxy «proxy» --daemon- 
mode 


Where: 


«endpoint» is in the format of username:passwordQurl if you are not using a vault. Only 
url is needed when you are using a vault. 


«image» is the image Id (e.g. “6d9ae1a5c970”) or repository name:tag (e.g. 
“library/centos:centos72” or “java:latest”) for the container image you want to instrument 
using CLI mode. The image must be present locally where you're running the CLI 
command. 


«policy id» is the policy Id (e.g. “5fd20b4321dabf0001fdc464”) for the policy you want to 
immediately apply to the image being instrumented using CLI mode. 
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Option 2: Run docker compose file 


This option is for using the instrumenter microservice to instrument images from the 
registry. Passing QUALYS GATEWAY ENDPOINT is required. 


QUALYS GATEWAY ENDPOINT-"«qualys username»:«qualys password>@<api_ 
gateway url>/crs/v1.2" docker-compose up 
Note: Use this command at the directory level where the docker compose file is present. 


Please edit the fields in the docker compose file and remove # to uncomment and declare 
the constant you would like to use. See File parameters for guidance. 


LI MQURL: qas://$(QUALYS GATEWAY ENDPOINT) # set the usernam 
password and qualys endpoint for instrumenter in env or directly to 
this file 


VAULT CONFIG (Change these settings if you have your own vault) 
I VAULT SECRET ENGINE: "kv-v2" 

‚I VAULT DATA VALUES BASE64: "false" 

iI VAULTPATH: "S(USER VAULT PATH)" 

I VAULT TOKE 


ij 
Z 
m 


"s (VAULT TOKEN p" 
‚I VAULT ADDRESS: "http://vault:8200" 


PROXY SETTINGS (Uncomment and fill required values for proxy) 
LI ALLOWHTTPPROXY: true 

https proxy: http://squid:3128 

LI MOSKIPVERIFYTLS: true 


I 


Option 3: Run kubernetes instrumenter.yml 
This option is for using the instrumenter microservice to instrument images from the 
registry. 


Edit the required field QUALYS GATEWAY ENDPOINT in the kubernetes file. Replace 
QUALYS GATEWAY ENDPOINT with the following: 


<qualys username»:«qualys password>@<api_ gateway url»/crs/v1.2 


Edit the vault and proxy fields, as required. See File parameters for guidance. 


- name: LI MQURL 
value: qas://((QUALYS GATEWAY ENDPOINT}} # Enter the usernam 
password of crs and qualys instrumenter pod endpoint 


# VAULT CONFIG Change these settings if you have your own vault 
# - name: LI VAULTPATH 

# value: /secret/data/qgsuser # Enter path where the vault 
credentials reside 
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value: 


- name: 
value: 


value: 


host) 
- name: 
value: 


- name: 


value: 


Deploy the Instrumenter Service 
Option 3: Run kubernetes instrumenter.yml 


jl VA 


‚I VA 


http: 


ULT ADDRESS 
//vault:8200 # Change if you have your own vault 
ULT DATA VALUES BASE64 


"fal 


credentials in 


jl VA 


vault 


se" # Change if you store base64 version of 


ULT SECRET ENGINE 


kv-v 
I VA 


2 # Set the version of vault engine you use 
ULT TOKEN 


Lr] 


{ {VA 


LI AL 


true 


LI MỌ 
true 


I 


ULT TOKEN}} # Set the vault token that you use 


proxy settings (Uncomment this if you have a proxy in your docker 


LOWHTTPPROXY 


- name: https proxy 
value: http://proxy:3128 


SKIPVERIFYTLS 


Then launch instrumenter using the following command: 


File parameters 


kubectl apply -f instrumenter.yml 


Regardless of the option you picked for deploying the Instrumenter service, there are 
certain user/platform specific parameters you'll need to provide. See the table below. 


General Description 
Username Your Qualys username. 
Password Your Qualys password. 


API Gateway URL 


The Qualys API Gateway URL where your Qualys account 
resides. To identify your Qualys platform and get the API 
URL, visit: https://www.qualys.com/platform- 
identification/ 


Docker URL The default docker URL is: 
tcp://qualys-docker-proxy.dockersock.jail:2375 
Endpoint The endpoint should be formatted as: 


«qualys username»:«qualys password»Q«api gateway . 
url»/crs/v1.2 


Example: 


qualys joe:abc12345Qgateway.qg1.apps.qualys.com/crs/v 
1,2 
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Deploy the Instrumenter Service 
After the Instrumenter service has been deployed 


Proxy 

Is Proxy/Allow Proxy Set to "true" to define proxy settings if you have a proxy in 
your docker host. 

Proxy Enter the proxy address. Sample: http://squid:3128 

Skip TLS Set to "true" to skip TLS verification. 

Vault 

Engine Enter the version of vault engine. Sample: kv-v2. 

Base64 Set to "false" by default. Change to "true" if you store 
base64 version of credentials in the vault. 

Path Enter the path where the vault credentials reside. 
Sample: /secret/data/qgsuser 

Token Enter the vault token that you use. 

Address Enter the vault address. Sample: http://vault:8200 


After the Instrumenter service has been deployed 
Check the instrumenter logs to verify the instrumenter is online and functional. 


docker logs instrumenter | grep "Awaiting InstrumentRequests" 


The output should print something similar to: 


"[2020-05-26T21:37:52Z2] DEBUG instrumenter: Awaiting 
InstrumentRequests" 


Troubleshooting the Instrumenter service 


Credentials issues when deploying without a vault service 


If you are not using a vault service, your Qualys credentials are being passed in plain text 
in a URL. If you are using special characters in your password (recommended), you will 
need to encode the special characters using HTML encoding. 


HTML encoding site for reference: https://www.w3schools.com/tags/ref_urlencode.ASP 


Logging 
To view logs for the CRS instrumenter, run "docker logs instrumenter" 


To view logs for the Docker socket proxy, run "docker logs proxy" 
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Instrument images from the UI 


Instrument Container Images with Qualys 
Instrumentation 


You have two options for instrumenting images: 
Instrument images from the UI 


Instrument images using CLI mode 


Instrument images from the UI 


This option uses the Instrumenter service. Once the Instrumenter service is up and 
running in your environment, you can instrument your images. Only images that have 
been scanned by a registry scan job (registry sensor) will have the Instrument option in 
the UI. To find the images you can instrument from the UI, go to Assets » Images and 
perform a search using this search query: source: REGISTRY 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 20 


DECEM Images RICO CUS 


source: REGISTRY 


6 0 


Total Images 


0 0 


Images detected without CS Sensor Images with Sev 5, 4 Vulnerabilities Docker Hub Official Images 


You can add additional search fields to help narrow down the list further. Then, in the 
search results, identify the image you want to instrument and pick Instrument from the 
Quick Actions menu. 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Assets Images MEISTEN Du 


source:REGISTRY and repo.registry: 'registry-1.docker.io* 


3 0 


Total Images 0 0 
Images detected without CS Sensor Images with Sev 5, 4 Vulnerabilities Docker Hub Official Images 
NO REMAINING FILTERS = | Actions (1) v 1-3of 3 
registry-1.docker.io qualysdemo/rwalwa... Jul 08, 2020 I centos8.1.1911 0 = 
Image Id: e5386b7edeaf 
On Hosts: 0 
registry-1.docker.io — Apr 13, 2018 | o = 
4 Quick Actions v 0 
On Hosts: 0 
registry-1.docker.io View Details Apr 13, 2018 | postores 0 = 


On Hosts: 0 


Delete 
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Instrument Container Images with Qualys Instrumentation 
Instrument images using CLI mode 


On the Instrument Image page, choose the source registry. You'll notice that the 
destination registry has the same value as the source registry. Click Instrument again. 


Instrument Image 


Select the source registry from where to instrument the image, and then provide the destination 
registry to store the instrument image 
Source Registry 
registry-1.docker.io 
Source Repositories 


qualysdemo/dontdelete 


Source Tag(s) 
[javai 


Destination Registry 


Destination Tag(s) 


| iava01-tayered 


Con | - | 


What happens next? 


The Instrumenter service will pull the image down, add in our solution and push the 
image back to the destination registry. 


Note the destination tags 


Take note of the destination tag(s) assigned to the instrumented image. We take the 
source tag and append -layered to create the destination tag. For example, in the example 
above, you'll see that the source tag is java01 and the destination tag is java01-layered. 
You'll be able to search for instrumented images by the destination tag. 


Instrument images using CLI mode 


The Instrument option in the UI lets you instrument container images that have been 
scanned by a registry scan job (registry sensor). Use the CLI mode option to instrument 
any image on your local host directly without the need for a registry scan. The image is 
not pushed to any repository because the instrumentation happens locally. The new - 
layered instrumented image will appear on the local machine and in the Container 
Security UI. 


How it works 


When you instrument an image using CLI mode, we'll immediately add in our solution 
and create the instrumented image (appended with -layered) at the same location. One 
command will instrument one image only, and then it will exit as soon as the 
instrumentation is done. The instrumented image will appear in the Container Security UI 
where you can view details about it. 


18 


Instrument Container Images with Qualys Instrumentation 
Instrument images using CLI mode 


Prerequisites 


- Request access to the Docker Hub private repo for qualys/crs-cli-instrumenter. To 
request access, reach out to Qualys Support from qualys.com/support and be sure to 
include your Docker Hub ID in your message. 


- Run docker login with the provided Docker Hub ID on the instance where you will run 
instrumenter.sh in CLI mode. 


Using CLI mode 

1) Pull the docker CLI files from github. You can download them from 
https://github.com/Qualys/qualys_crs_instrumenter 

2) Edit instrumenter.sh to configure user specific details for proxy and vault usage. 


3) Run the docker CLI script with the minimum required parameters. The script will run 
with CLI mode enabled by default. Required fields are endpoint and image. Policy ID is 
optional. (See Deploy the Instrumenter Service to learn about additional options.) 


./instrumenter.sh --endpoint <endpoint> --image <image> [-- 
policyid <policy id>] 


For example: 


./instrumenter.sh --endpoint "qualys joe:my- 
passwordügateway.qgl.apps.qualys.com/crs/v1.3" --image 
"6d9aela5c970" [--policyid "5fd205b4321dabf0001fdc464"] 


Where: 


«endpoint» is in the format of username:passwordQurl if you are not using a vault. Only 
url is needed for the endpoint when you are using a vault. 


«image» is the image Id (e.g. “6d9ae1a5c970”) or repository name:tag (e.g. 
"library/centos:centos72"or “java:latest”) for the container image you want to instrument. 
The image must be present locally where you're running the CLI command. 


«policy» is the policy Id (e.g. "5fd20b4321dabf0001fdc464”) for the policy you want to 
immediately apply to the instrumented image. 


Instrumented image appears in the UI 


You'll see instrumented images on the Assets » Images list. Note that for these images 
there is no value shown in the Registry column since these were instrumented on the local 
host using the CLI mode (not pulled from the registry). Also, these images have not been 
scanned yet so there are no vulnerabilities shown. 
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Instrument Container Images with Qualys Instrumentation 
View details for instrumented container 


View details for instrumented container 


To find the instrumented container, go to Assets » Containers and perform a search using 
this search query: isInstrumented: true 


Container Security ~ HOME DASHBOARD 


ASSETS 


EVENTS REPORTS CONFIGURATIONS 20% 


Assets 


[DESEE Containers EU 


< isInstrumented:true 


4 0 0 0 0 


Total Containers 
Privileged Containers Containers detected without CS Sensor Containers in Drift 


Then choose View Details from the Quick Actions menu for any container listed as a 
result of your search. 


Container Security v HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 208 


DEO EMI MEE Containers MATOS 


2X isInstrumented:true 


4 0 0 0 0 


Total Containers 


Root Containers Privileged Containers Containers detected without CS Sensor Containers in Drift 
NO REMAINING FILTERS E Actions (1) Y 1-40f 4 
ONTAINER CREATED ON v HO: STATE LAST SCANNED VULNERABILITIES 
7 - Jul 27, 2020 RUNNING = 
Container id: a Quick Actions Y 16 days age 
- Jul 27, 2020 RUNNING 
Container Id: à 15 days ago 


Go to the Events tab to view Standard and Behavior logs (pick the type of logs you want to 
view from the Filter by menu). You can use the details you find here to configure policies. 


< View Details: c30017b5bb02 


View Mode 
| Filter by: Behavior 1-50 of 320 g 
Summary 
PROCE ACTION TIME 

Container Details 

/bin/cat 198 5 /lib/x86. 64-linux-gnu/libc-2.19.so - Allowed | September 8, 2020 = 
Events 09:04:49AM 
Runtime Profile /bin/cat 198 5 /usr/lib/locale/C.UTF-8/LC_ADDRESS Allowed | September 8, 2020 

09:04:49AM 

Network 

/bin/sh 186 109 198 Allowed | September 8, 2020 
Services/Users 09:04:49AM 
Ml Ed /bin/cat 198 Jetc/hosts Allowed | September 8, 2020 
Associations M 
CIA /bin/cat 198 5 /dev/pts/1 | Alowed | September 8, 2020 


09:04:49AM 


The system call number is shown in the CALL column. Please refer to Appendix A - 
System Calls to look up any system call number. 
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Configure and Apply Policies 
About Policies 


Configure and Apply Policies 


Create runtime policies with the rules you want to enforce, and then assign policies to 
instrumented images. Apply a policy to an instrumented image in order to enforce certain 
behavioral restrictions and secure the container spawned from the image. 


About Policies 


A runtime policy contains one or more rules of different types along with the mode the 
policy operates on, the default action for various rule types, whether to enable or disable 
the behavioral learning mode and more. New policies can be created from scratch or by 
auto-generating a behavioral profile policy from a running container (see Behavioral 
Learning). When defining a policy, you can change the default action for each rule type. 


The core technology behind most policy rules is the idea of a “function-level” (syscall) 
firewall; a policy rule can specify whether a program should or should not be able to 
execute a particular function (syscall), given a specific set of arguments. Each rule 
specifies a program that the rule matches, along with a rule type, whether the rule is 
enabled or disabled, and then the arguments that are required for that type of rule. 


Policy rule types 


There are three basic policy rule types: network, file, and application (syscall/function). 


Network rules 


A network rule at first glance can provide "standard" firewall capabilities - allowing or 
denying inbound or outbound IP connectivity between the container and a given IP 
address and port to block lateral or external communication. The network rule has these 
types: Network Outbound and Network Inbound. 


File rules 

File rules control what files can be accessed by a specific program.The file rule has these 
types: Read and Write. 

Application rules 


Application rules are in a way a superset of the other rule types. With application rules, 
one can directly specify the system call that should be filtered. With the other types, 
Container Runtime Security (CRS) translates the rule to the appropriate one or more 
system calls. For example, a file rule to deny a file translates to syscall 0 (sys read) and 2 
(sys open).The application rule has one type: Syscall. See Appendix A - System Calls. 
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Configure and Apply Policies 
About Configurations 


Behavioral Learning 


Note: This feature is available via the CRS API for advanced users. Please refer to the 
Qualys Container Runtime Security API Guide for complete details. 


Container Runtime Security can automatically learn the behavior of the application in 
your environment by recording the activities being performed in the container. It captures 
all the network communication whether it is lateral or external, all the files read by any 
programs, program/processes and the system calls called in the container to create a 
baseline security policy template that can be a new policy or merged with the existing 
policy applied to the container. 


Customers can start with enabling behavioral learning for their images in the test 
environment to understand the basic expected behavior of the container and how it 
differs from the build image. You can use CRS to create a policy template based on the 
learned behavior and get alerted if any violations occur. 


Note: Behavioral logging, logging mode and policy mode can be changed for a specific 
container. 


About Configurations 


Configurations can be applied only to images with instrumentation in them (via UI). When 
you apply a configuration to the container image, all the containers spawned from that 
image are secured and adhere to your configuration. A change to the configuration 
assigned to the image will be applied to all the running containers. 


You can also apply a specific configuration to containers directly in the absence of an 
image assigned policy (only via API). . 


Image Container 

Config Application Applied via UI Applied via API 
General; applies to all Specific; applies to the 
containers spawned by the specific containers only 


instrumented image 


Config Usage Day to Day Operational usage Troubleshooting, Incident 
Response, Forensic 


Configuration via UI consists of two objects - Policy and LogMode. More parameters are 
available via the API. Once a configuration is created, it can be assigned to images and 
containers via the API. From the Ul it's only possible to update the policy and logmode for 
a given instrumented image (source:INSTRUMENTATION). 
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Configure and Apply Policies 
Create new policies 


Configuration components 
Configuration components (via UI) include: Policy and LogMode. 


Policy 


The policy is a component that contains one or more rules of different types along with 
the mode the policy operates on, the default action for various rule types, whether to 
enable or disable the behavioral learning mode and more. 


LogMode 


You can choose from the following LogMode options to determine which policy hit events 
should be logged: 


None - No events get logged. 

PolicyMonitor - Only policy hit events with Monitor action. 

PolicyDeny - Only policy hit events with Deny action. 
PolicyMonitorDeny - Only policy hit events with Monitor or Deny action. 


PolicyAllow - Only policy hit events with Allow action. 


PolicyAll - Only policy hit events with Monitor, Deny or Allow action. 
Behavior - Only detailed behavioral events. 
All - Includes events that match PolicyAll plus events that match Behavior. 


See Configure Instrumentation to learn how to choose the LogMode for an image. 


Create new policies 
Define runtime policies with rules for monitoring and securing running containers. 
Go to Configurations » Runtime Policies, and then click the New Policy button. 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Configurations 


New Policy 


Basic Details 


Sensors Integrations Runtime Policies 


Under Basic Details, you'll provide a policy name and description, and choose a policy 
enforcement mode (Active, Inactive, Permissive). The option you pick determines whether 
or not the policy rules will be enforced on the containers that are spawned from the 
image. The policy is enforced only when Active is selected. When Permissive is selected, 
the events are reported but actions are not enforced. Note that you can change this at any 
time after the policy is saved. See Set policy enforcement to learn more. 
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Configure and Apply Policies 
Create new policies 


<- Create New Policy 


STEPS 1/2 Basic Details 


Provide policy information 
© Basic Details 


à Poli 
Descripti 
Policy Mode 


Choose whether to enforce the rules in this policy. Inactive means the policy is not enforced. Active means the policy is enforced 
Permissive means policy is evaluated, events are reported but rule actions are not taken 


Inactive 
Active 
Inactive 
Permissive pr each rule category. Only syscalls corresponding to specified rules are monitored. The default action is taken 
3g policy rule for a syscall being inspected 
^w Network 
When there are no matching Network rules, the following action will be applied @ Allow 


v 


Next, choose default actions for Network, File and Application rule types. This is the 
default action that will be taken unless there is a policy rule that overwrites this action. 


For example, you can choose Allow as the default action for Network rules to allow all 
inbound and outbound traffic to/from the instrumented container and then set up 
specific Network rules to deny traffic to a particular IP address and port. 


For Application rules, the default action only applies to rules with an Execution system 
call selected. 


Default Actions 


Choose a default action for each rule category. Only syscalls corresponding to specified rules are monitored. The default action is taken 
when there isn't a matching policy rule for a syscall being inspected 


^w' Network 
Allow 
When there are no matching Network rules, the following action will be applied o 
O Allow 
E File QD 
eny 
When there are no matching File rules, the following action will be applied 
[<>] Application 
When there are no matching rules with an Execution system call, the following action will be applied © Allow 


Scroll down further to define a list of system calls that you want to ignore for the policy. 
Add one or more system calls from the drop-down list. When a system call is ignored, no 
new events will be created for the system call even if it matches one of the policy rules. 
This will save you from having to modify all the rules that include a particular system call 
you want to ignore. 
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Configure and Apply Policies 
Create new policies 


If you want to start getting events for an ignored system call in the future, simply edit the 
policy to remove the system call from the ignored system calls list. You'll be able to 
remove individual system calls or clear the entire list. 


Ignored System Calls 


Select system calls to ignore for this policy. No new events will be created for ignored system calls even if they match policy rules. 
Remove a system call from this list to get events again. 


sys execve 
sys. kill 
sys. uname 


sys. kexec. load i v 


Rules 


Go to the Rules tab to add policy rules. You can add as many rules as you like. Simply click 
the Add Rule button for Network Rule, File Rule or Application Rule. See Rule Types below 
to understand the parameters you'll set for each rule type. 


€— Create New Policy 


STEPS 2/2 
Rules 
Basic Details Add policy rules. For each rule, provide rule parameters and the action to take when a system call with the specified parameters is 
encountered 
Rules (Optional) 
Y A, Network Rules (0) Default Action 
Define inbound and outbound network rules © Allow 
+ Add Rule 
w [E File Rules (0) Default Action 
Define read and write file access rules 
© Allow 
+ Add Rule 
y [Æ] Application Rules (0) Default Action 
Define application rules for any supported system call (For rules with Execution syscall) 
+ Add Rule © Allow 
Cancel Previous | 


For each new rule, give the rule a name, choose the rule type, set a rule action, and choose 
whether the rule is enabled or disabled. When you're done, click Add Rule to save it to 


your policy. Optionally, click Save and Add another to save the rule and create another 
rule of the same type. 


When you're done adding rules, click Save. Your new policy will appear on the Runtime 
Policies list where you can manage it. 


25 


Rule Types 


Configure and Apply Policies 
Create new policies 


Here's a look at the types of rules you can add to your policies and the parameters you'll 
need to provide for each rule type. For Network and File rules, we watch particular system 
calls by default. For Application rules, you'll pick the system call the rule applies to. 


Rule 
Category 


Rule 
Type 


Default 
System Call 


Rule 
Parameters 


Description 


Network 


Network 
Outbound 


sys connect 


IP Address & 
Port 


Allow, deny or monitor outbound 
traffic. The IP & port refers to the 
destination IP and port to which the 
process in the instrumented 
container is either to be allowed, 
blocked or monitored. When port is 
left blank, it acts as a wildcard (*). 


Network 


Network 
Inbound 


sys accept, 
sys accept4 


IP Address & 
Port 


Allow, deny or monitor inbound 
traffic. The IP refers to the source IP 
from where the request is made to 
the instrumented container. Port 
refers to the bind port or container 
port. When port is left blank, it acts 
as a wildcard (*). 


File 


Read 


Sys open 


Program & File 


Allow, deny or monitor read access 
to a particular file by a particular 
program 


File 


Write 


Sys write 


Program & File 


Allow, deny or monitor write access 
to a particular file by a particular 
program 


Application 


Syscall 


user selected 
system call 


Program, 

Argument 1, 
Argument 2, 
Argument 3 


This is an advanced rule type. You 
must be familiar with the selected 
system call to know the arguments, 
if any, that must be defined for the 
system call. 


Note that a rule with an Execution 
syscall only applies to the parent 
program defined in the rule and not 
child programs spun up from the 
parent program. In other words, the 
child program may be allowed to 
execute a file that the parent 
program is prevented from 
executing. 


Use * to prevent all programs from 
executing a certain file. 
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Configure and Apply Policies 
Manage your policies 


Using the API? 


You can also create and update policies using the Container Runtime Security API. Once 
saved, your policies will appear in the Container Security UI. 


When using the API, you have the option to auto-generate a policy based on what's been 
observed for your instrumented container. You'll use the following API endpoint to build a 
policy based on a container's behavior: 


/csapi/vl.2/runtime/containers/(containerSha]/template 


Please refer to the Qualys Container Runtime Security API Guide for complete details on 
API endpoints, input parameters and samples. 


Manage your policies 


You can view, update and delete policies from the Runtime Policies list. You can also 
change the policy enforcement mode. 


Go to Configurations » Runtime Policies to get started. You'll see a list of the saved 
policies in your account. Choose an option from the Quick Actions menu. 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Configurations 


Prevent tampering to host Active. Jul 17, 2020 Oct 27, 2020 
Modifications to 'hosts' and 'resolve.conf file can result in resolution of Domain name to mal Quick Actions v 


Default Policy View Details Active Jul 16, 2020 Jul 16, 2020 


Default group policy 


View Details 


Select View Details for any policy in the list to see more details about the policy. You'll see 
basic details like policy name, description and creation date, plus default actions for the 
different rule types. You'll also see the rules that make up the policy. 

Activate, Deactivate, Permissive 


Choose one of these options to change the enforcement mode for the policy: Activate, 
Deactivate, Permissive. See Set policy enforcement to learn about these options. 
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Configure and Apply Policies 
Manage your policies 


Edit Policy 


Choose Edit from the Quick Actions menu to make changes to a policy. You can make 
changes to any of the policy settings and policy rules. On the Rules tab, expand a rule type 
to see all the rules for that type. Edit and delete individual rules, and add new rules. Click 
Save when you're done making changes to the policy. 


< Edit Policy: Prevent tampering to host 


Default Action = 


Edit Mode Y Network Rules (0) 
en hs O Allow 
Define inbound and outbound network rules 
+ Add Rule 
y [5] File Rules (0) Default Action 
Define read and write file access rules O Allow 
+ Add Rule 
A [Æ] Application Rules (2) Default Action 
Define application rules for any supported system call (For rules with Execution syscall) 
© Allow 


- [oc NM 


syscall . sys. write etc/hosts o 


si 


Edit syscall a sys. write /etc/resolvconf & 


Delete Policy 


Choose Delete from the Quick Actions menu for the policy you want to remove. Note that 
you can only delete policies that are not associated with instrumented images/containers. 
You'll see an Error if the policy is associated with an image/container. In this case, you 
must disassociate the policy and then try again. 


Tip - To find instrumented images/containers, go to Assets > Images or Assets > 
Containers and use the following query. 


Search query: 
isInstrumented:true 
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Set policy enforcement 


Set policy enforcement 


We provide three policy enforcement options, which determine whether or not the policy 
rules will be enforced on the containers that are spawned from the image. When testing 
new policies, we recommend you set the policy to Permissive mode, which allows you to 
see the rule hits without actually enforcing the rules. 


Identify a policy in the list and choose from these policy enforcement options on the Quick 
Actions menu: 


Activate - Activate the policy on all images that have the policy applied. The policy gets 
enforced on all containers spawned from that image. 


Deactivate - Deactivate the policy on all images/containers where its been applied. This 
may be needed if you are troubleshooting an issue and want to stop policy enforcement. 


Permissive - Put the policy in permissive mode. When in permissive mode, the rules in the 
policy will not be enforced but all activity is logged for rule hits. This is recommended 
when starting out with a new policy so you can get an idea of the rule hits which will allow 
you to go back and fine tune the policy to make sure it's working as you expected. 


Apply policy to instrumented image 


Apply a security policy to an instrumented image to enforce certain behavioral 
restrictions and secure the container spawned from that image. The first thing you'll want 
to do is find your instrumented image. 


Go to Assets » Images and perform a search using this search query: 
source: INSTRUMENTATION. 


Then choose Configure Policies to select the policy you want to apply to the image. 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 203 


Assets Images 


Containers Registries 


source: INSTRUMENTATION 


1 
Total Image 0 1 0 


Images detected without CS Sensor Images with Sev 5, 4 Vulnerabilities Docker Hub Official Images 


REGISTRY E) | actions) v 1-10f 1 


docker.io 1 


registry-1.docker. 1 


a dockerio MEME x3] men | sshttestiayered — 3 1 


Quick Actions 
View Details 
Configure Policies 


Configure Instrumentation 


Delete 
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Configure and Apply Policies 
Apply policy to instrumented image 


You'll see a list of policies defined in your subscription. Select the policy you want to 
assign to the image. You can choose only one policy. Then click Apply. 


Select Policy 


Select a policy to apply to the image. Only one policy can be applied to an image. 


NAME DESCRIPTION 


Default Policy Default group policy 


Deny Write Static Websit... ^ Example policy that prevents static website files from being altered i 


No Access to Passwd fro... Example policy denies sys open to /etc/passwd from program cat 


Block bad IP Example policy that block bad IP 


30 


Configure Instrumentation 
Select the LogMode 


Configure Instrumentation 


Once a policy is applied to an image you can choose a LogMode to determine what is 
logged in a container for policy hits (rule matches) and behavior. 


Select the LogMode 


Go to Assets » Images and perform a search using this search query: 
source: INSTRUMENTATION. 


Then choose Configure Instrumentation from the Quick Actions menu of an 
instrumented image to select the LogMode. 


he 
© 
K 


Container Security L HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 


Assets 


X source: INSTRUMENTATION 


1 


Total Image 0 1 0 
Images detected without CS Sensor Images with Sev 5, 4 Vulnerabilities Docker Hub Official Images 
REGISTRY v Actions (1) v 1-10f 1 
dockerio 1 
registry-1.docker.... 1 REGISTRY REPOSITORY CREATED ON v TAGS CONTAINERS VULNERABILITIES 
A docker.io Ee ‘Sep 09, 2020 | sshetestlayered 3 1 
Quick Actions v = — 
On Hosts: 1 
View Details 


Instrument 
Configure Policies 
Configure Instrumentation 


Delete 


Choose an option from the LogMode menu, and then click Apply. Your selection will 
determine which policy hits get logged in the container security UI. 


Configure Instrumentation 


Provide instrumentation code to gather trace information 


LogMode 
PolicyMonitorDeny 

None - - No events 
PolicyMonitor - - Only policy hit events with monitor action 
PolicyDeny - - Only policy hit events with deny action 
PolicyMonitorDeny - - Only policy hit events with monitor, deny a 
PolicyAllow - - Only policy hit events with allow action 
PolicyAll - - Only policy hit events with monitor, deny, allow actior 
Behavior - - Only detailed behavioral events 


All - - Includes PolicyAll & Behavior 
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Configure Instrumentation 
Run containers from instrumented image 


Run containers from instrumented image 
You can now spawn a container from the instrumented image. 


docker run -itd -e LI MQURL=https://<cmsqagpublic VIP»/crs/v1.2 =e 
LI MOSKIPVERIFYTLS-true «your registry/repo:tag> 


The policy applied to the instrumented image gets enforced on the container and 
activities are logged as per the selected log mode. 


Proxy Settings 


You'll need to provide proxy details if the instrumented container is running behind a 
proxy to allow the CRS instrumenter to talk to the Qualys backend. The instrumented 
container can be launched with any of following proxy environment variables. If multiple 
proxy environment variables are used, then they will be honored in the order shown 
below. 


-e LI HTTPS PROXY-«proxy» 
-e LI HTTP PROXY-«proxy» 
-e HTTPS PROXY-«proxy» 
-e HTTP PROXY-«proxy» 


The following example uses the LI HTTPS PROXY environment variable: 


docker run -itd -e LI MQURL=https://<cmsqagpublic VIP»/crs/v1.2 =e 
LI MOSKIPVERIFYTLS-true -e LI HTTPS PROXY=<proxy> «your 
registry/repo:tag» 


View details for instrumented container image 


Go to Assets » Containers and perform a search using this search query: 
isInstrumented: true 


n 


Then choose View Details from the Quick Actions menu for any container listed. 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 20 m 


Assets D HEEL Containers 


Registries 


isInstrumented: true 


A 0 0 0 0 


Root Containers Privileged Containers Containers detected without CS Sensor Containers in Drift 


Total Containers 


NO REMAINING FILTERS = | Actions (1) v 1-4of 4 


- Jul 27, 2020 - RUNNING 


Container Id: a Quick Actions v 


- Jul 27, 2020 - RUNNING 
Container Id: 4 15 days ago 


15 days ago 
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Configure Instrumentation 
Enable Additional Daemon logging (Optional) 


The Runtime Profile tab shows the resources that are tracked to gather trace information. 
It shows the files that are being read on the container, programs being run, ports accessed, 
and IP address information. 


<- View Details: c30017b5bb02 


View Mode . 
Runtime Profile 


Last known information for this container 
Summary 


Container Details 
FILES READ PROGRAMS RUN PORTS ACCESSED IP ADDRESSES COMMUNICATED 
— 


Events 

bin/bash 
Runtime Profile 

bin/cat 
Network 
Services/Users 
Installed Software 


Associations 


Vulnerabilities 


The Events tab shows a log of when each resource being tracked is accessed, and whether 
the access was allowed, monitored or denied depending on the applied policy. You can use 
the filter option to view standard logs or behavior logs. Standard logs show policy hits. 
Behavior logs show system calls. The system call number is shown in the CALL column. 
Please refer to Appendix A - System Calls to look up any system call number. 


Tip - Use the details you find here to create new runtime policies. 


< View Details: c30017b5bb02 


View Mode 


Filter by: Behavior 1-50 of 320 
Summary 
Container Details 
/bin/cat 198 5 /lib/x86. 64-linux-gnu/libc-2.19.so Allowed September 8, 2020 = 
Events 09:04:49AM 
Runtime Profile /bin/cat 198 5 Jusr/lib/locale/C.UTF-B/LC_ADDRESS Allowed September 8, 2020 
09:04:49AM 
Network 
/bin/sh 186 109 198 Allowed September 8, 2020 
Services/Users 09:04:49AM 
Installed Software /bin/cat 198 e /etc/hosts Allowed September 8, 2020 
09:04:49AN 
Associations LE 
/bin/cat 198 5 /dev/pts/1 Allowed September 8, 2020 


Vulnerabilities E 
09:04:49AM 


Enable Additional Daemon logging (Optional) 


After you've successfully instrumented an image, if you need to enable logging for 
troubleshooting the daemon you have two options. Option 1 covers spawning a container 
from the instrumented image with specific logging config environment variables. Option 2 
is to edit the daemon.toml file in an already instantiated container and provide the 
logging config, then restarting the daemon process. The logging config will enable 
additional daemon log levels. 
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Enable Additional Daemon logging (Optional) 


Log levels 


The following log levels are supported. Please note that log levels have a certain hierarchy 
as listed below. When you choose a log level, all levels below it are also included. For 
example, a level of "trace" includes all other levels since it's at the top of the hierarchy. A 
level of "error" includes fatal and panic but not warn, info, debug or trace. 


Log levels: 
- trace 

-- debug 
--- info 
---- warn 


How to enable daemon logging 
You can enable daemon logging using either of the options described below. 


Option 1: Use environment variables 


Use LI LOGLEVEL to specify the log level you want, and LI DAEMONLOG to specify the log 
file and path where the daemon should write logs. Run the following command: 


docker run -itd -e LI MQSKIPVERIFYTLS-true -e LI LOGLEVEL-"«log- 
level>" -e LI DAEMONLOG-"«path/filename»" <repo:tag> 


Example: 


docker run -itd -e LI MOSKIPVERIFYTLS-true -e LI LOGLEVEL-"debug" 
-e LI DAEMONLOG-"/tmp/daemonlogs new" my-repo:my-tag 


Option 2: Edit the toml file 


Go to /etc/layint and edit the daemon.toml configuration file. Append the following config 
options to specify the log level and file path: 


logLevel - "«log-level»" 

daemonLog = "«path/filename»" 
Example: 

logLevel - "debug" 

daemonLog = "/tmp/daemonlogs new" 


Note: You will need to restart the daemon process for this change to take effect. 
Note: A valid directory path must be present inside the container. 
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Drill-down into event details 


View Your Events 


Runtime events will be listed on the Events tab. Here you can search events and drill- 
down into event details. Use options on the left side bar to quickly find events by the 
action taken (Allowed, Monitored, Denied) and the event type (Behavior, Standard). 


Use the search field above the list to find events by event details like the container SHA 
the event is associated with, system call, process, and more. 


Container Security v HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 20% 


Q Search for event... Last7 Days v = 


918 


1-50 of 918 | 
Total Events 
Sd 
99cfbd11e113 Behavior — |' Allowed! ^ /usr/lib64/libc-2.17.s0 Jusr/bin/cat 3 sys. close August31,20200 ~ 
Process Id: 85 06:53:19AM 
ACTIONS 
— ma 99cfbd11e113 Behavior Allowed /eto/ld.so.cache Jusr/bin/cat 3 sys_close August 31, 2020 
Monitored 6 Process Id: 85 06:53:19AM 
PEL = 99cfbd11e113 Behavior ÜBEN]  /etc/ld.so.cache Just/bin/cat 5 sys_fstat August 31, 2020 
Process Id: 85 06:53:19AM 
TYPES 
Behavior 914 99cfbd11e113 Behavior "Allowed" /lib64/libc.so.6 Jusr/bin/cat 2 sys_open August 31, 2020 
Standard 4 Process Id: 85 06:53:19AM 
99cfbd11e113 Behavior Allowed] — /usr/lib64/libc-2.17.so Just/bin/cat 5 sys. fstat August 31, 2020 
Process Id: 85 06:53:19AM 
99cfbd11e113 Behavior Allowed /usr/lib64/libc-2.17.50 Jusr/bin/cat - sys_read August 31, 2020 
Process Id: 85 06:53:19AM 
99cfbd11e113 Standard passwd /usr/bin/cat 2 Sys open August 31, 2020 
Process Id: 85 06:53:19AM 
99cfbd11e113 Behavior Allowed /eto/ld.so.cache Jusr/bin/cat 2 sys_open August 31, 2020 
Process Id: 85 06:53:19AM id 


Drill-down into event details 
You can choose from the following Quick Action options for any event in the list: 


View Details - Select this option to get event details like the process, system call, file 
name and action. 


View Container Details - Select this option to see container details, including events, 
runtime profile, container information, associations and vulnerabilities. 


Container Security Y HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 20 


Q search for event... Last7 Days v = 


918 


Total Events 330918 3 
IER ID yP STION N ROC 
ENG Behavior Allowed | /usr/lib64/libc-2.17.so Jusr/bin/cat 3 sys_close August 31,2020 “ 
Suck Action x Process Id: 85 06:53:19AM 
ACTIONS 
Aland CD Behavior — | Allowed!  /etc/ld.so.cache Jusr/bin/cat 3 sys.close August 31, 2020 
Free F Process Id: 85 06:53:19AM - 
Denied 2 
i Behavior [Allowed]  /etc/ld.so.cache Jusr/bin/cat 5 sys_fstat August 31, 2020 il 
Process Id: 85 06:53:19AM | 
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View event details on dashboard 


View event details on dashboard 


Go to Dashboard and you'll see widgets with info about events like the number of events 
by action, event type and system call name. You'll also see the number of images that 
have been successfully instrumented and the number of images currently queued for 
instrumentation. 


Here's a sample dashboard. Check out the dashboard in your own account to see all 
widgets. 


Container Security HOME DASHBOARD ASSETS EVENTS REPORTS CONFIGURATIONS 20 


Container Security Overview + 


Last 30 Days v © 
IMAGE INSTUMENT EVENTS BY SYSCALL NAME ie 
sys-close "e 
sysfstat — 


SYS CALL 
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Appendix A - System Calls 


See the table below for supported system calls in numerical order along with the system 
call names and required arguments, if available. You can use this information when 
configuring runtime policies with rules targeting specific system calls. 


SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
0 Sys read filename 
1 Sys write filename 
2 Sys open filename 
3 Sys close filename 
4 Sys stat filename 
5 sys fstat filename 
6 sys lstat filename 
7 sys poll 

8 sys lseek 

9 sys mmap 

10 sys mprotect 

11 sys munmap 

12 Sys brk 

13 Sys rt sigaction 

14 Sys rt sigprocmask 

15 Sys rt sigreturn 

16 Sys ioctl 

19 Sys readv filename 
20 Sys writev filename 
21 SyS access 

22 Sys pipe 

23 Sys select 

24 Sys sched yield 

25 sys mremap 

26 sys msync 

27 Sys mincore 

28 sys madvise 

29 sys shmget 

30 sys shmat 

31 sys shmctl 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
32 sys_dup 

33 sys_dup2 

34 sys_pause 

35 sys_nanosleep 

36 sys_getitimer 

37 sys_alarm 

38 sys_setitimer 

39 sys_getpid 

40 sys_sendfile 

41 Sys socket domain type Socket 
42 Sys connect port address 
43 Sys accept port address 
44 Sys sendto port address 
45 sys recvfrom port address 
46 Sys sendmsg 

47 sys recvmsg 

48 sys shutdown 

49 sys bind port address 
50 sys listen 

51 Sys getsockname 

52 Sys getpeername 

53 Sys socketpair 

55 Sys setsockopt 

56 sys clone 

57 Sys fork 

58 sys vfork 

59 Sys execve filename 

60 Sys exit 

61 Sys wait4 

62 sys kill 

63 sys uname 

64 sys semget 

65 Sys semop 

66 sys semctl 

67 sys_shmdt 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
68 sys msgget 
69 sys msgsnd 
70 sys msgrcv 
71 sys msgctl 

72 sys fcntl 

73 sys flock 

74 sys fsync 

75 sys fdatasync 
76 sys truncate 
77 Sys ftruncate 
78 sys getdents 
79 sys getcwd 
80 sys chdir 

81 sys fchdir 

82 sys rename 
83 sys mkdir 

84 sys rmdir 

85 Sys creat 

86 sys link 

87 sys unlink 

88 sys symlink 
89 sys readlink 
90 sys chmod 

91 sys fchmod 
92 sys chown 

93 sys fchown 
94 sys lchown 
95 sys umask 

96 sys gettimeofday 
97 sys getrlimit 
98 Sys getrusage 
99 Sys sysinfo 
100 sys times 

101 Sys ptrace 
102 Sys getuid 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
103 Sys syslog 

104 Sys getgid 

105 Sys setuid 

106 Sys setgid 

107 Sys geteuid 

108 Sys getegid 

109 Sys setpgid 

110 Sys getppid 

111 sys getpgrp 

112 Sys setsid 

113 Sys setreuid 

114 Sys setregid 

115 sys getgroups 
116 Sys setgroups 
117 Sys setresuid 

118 Sys getresuid 

119 Sys setresgid 

120 Sys getresgid 

121 sys getpgid 

122 Sys setfsuid 

123 Sys setfsgid 

124 Sys getsid 

125 Sys capget 

126 Sys capset 

127 Sys rt sigpending 
128 Sys rt sigtimedwait 
129 Sys rt sigqueueinfo 
130 Sys rt sigsuspend 
131 sys_sigaltstack 
132 sys_utime 

133 sys_mknod 

134 sys_uselib 

135 sys_personality 
136 sys_ustat 

137 sys_statfs 


40 


Appendix A - System Calls 


SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
138 sys_fstatfs 

139 Sys sysfs 

140 Sys getpriority 

141 Sys setpriority 

142 Sys sched setparam 

143 Sys sched getparam 

144 Sys sched setscheduler 
145 sys sched getscheduler 
146 sys sched get priority max 
147 Sys sched get priority min 
148 Sys sched rr get interval 
149 sys mlock 

150 sys munlock 

151 sys mlockall 

152 sys munlockall 

153 sys vhangup 

154 sys modify ldt 

155 Sys pivot root 

156 Sys sysctl 

157 sys prctl 

158 sys arch prctl 

159 sys adjtimex 

160 Sys setrlimit 

161 sys chroot 

162 Sys sync 

163 Sys acct 

164 sys settimeofday 

165 sys mount 

166 sys umount2 

167 sys swapon 

168 Sys swapoff 

169 sys reboot 

170 Sys sethostname 

171 Sys setdomainname 

172 sys iopl 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
173 sys_ioperm 

174 sys_create module 
175 sys_init module 

176 sys_delete module 
177 Sys get kernel syms 
178 Sys query module 
179 Sys quotactl 

180 sys nfsservctl 

181 sys getpmsg 

182 sys putpmsg 

183 sys afs syscall 

184 sys tuxcall 

185 Sys security 

186 sys gettid 

187 sys readahead 

188 Sys setxattr 

189 sys |setxattr 

190 Sys fsetxattr 

191 Sys getxattr 

192 sys lgetxattr 

193 Sys fgetxattr 

194 Sys listxattr 

195 sys llistxattr 

196 sys flistxattr 

197 sys removexattr 

198 sys lremovexattr 
199 sys fremovexattr 
200 sys tkill 

201 sys time 

202 sys futex 

203 Sys sched setaffinity 
204 Sys sched getaffinity 
205 Sys set thread area 
206 Sys io setup 

207 Sys io destroy 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
208 Sys io getevents 
209 Sys io submit 

210 Sys io cancel 

211 Sys get thread area 
212 sys lookup dcookie 
213 sys epoll create 

214 sys epoll ctl old 
215 sys epoll wait old 
216 sys remap file pages 
217 Sys getdents64 

218 Sys set tid address 
219 Sys restart syscall 
220 Sys semtimedop 
221 Sys fadvise64 

222 sys timer create 
223 sys timer settime 
224 sys timer gettime 
225 sys timer getoverrun 
226 sys timer delete 
227 Sys clock settime 
228 Sys clock gettime 
229 Sys clock getres 

230 sys clock nanosleep 
231 Sys exit group 

232 sys epoll wait 

233 sys epoll ctl 

234 sys tgkill 

235 sys utimes 

236 Sys vserver 

237 sys mbind 

238 Sys set mempolicy 
239 sys get mempolicy 
240 sys mq. open 

241 sys mq unlink 

242 sys mq timedsend 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
243 sys mq timedreceive 
244 sys mq notify 

245 sys mq. getsetattr 
246 Syskexec load 

247 sys waitid 

248 sys add key 

249 Sys request key 

250 Sys keyctl 

251 Sys ioprio. set 

252 Sys ioprio get 

253 sys inotify init 

254 sys inotify add watch 
255 sys inotify rm watch 
256 sys migrate pages 
257 Sys openat 

258 sys mkdirat 

259 sys mknodat 

260 sys fchownat 

261 sys futimesat 

262 sys newfstatat 

263 sys unlinkat 

264 sys renameat 

265 sys linkat 

266 sys symlinkat 

267 sys readlinkat 

268 sys fchmodat 

269 Sys faccessat 

270 Sys pselect6 

271 sys ppoll 

272 sys_unshare 

273 Sys set robust list 
274 Sys get robust list 
275 Sys splice 

276 Sys tee 

277. sys_sync_file_range 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
278 sys_vmsplice 

279 sys_move_pages 

280 sys_utimensat 

281 sys epoll pwait 

282 sys signalfd 

283 sys timerfd create 

284 Sys eventfd 

285 sys fallocate 

286 sys timerfd settime 
287 sys timerfd gettime 
288 Sys accept4 

289 sys signalfd4 

290 Sys eventíd2 

291 sys epoll create1 

292 sys dup3 

293 Sys pipe2 

294 sys inotify init1l 

295 Sys preadv 

296 Sys pwritev 

297 Sys rt tgsigqueueinfo 
298 Sys perf event open 
299 sys_recvmmsg 

300 sys_fanotify_init 

301 sys_fanotify_mark 

302 sys_prlimit64 

303 sys_name_to_handle_at 
304 sys_open_by_handle_at 
305 sys_clock_adjtime 

306 sys_syncfs 

307 sys_sendmmsg 

308 sys_setns 

309 sys_getcpu 

310 Sys process vm readv 
311 Sys process vm writev 
312 sys kcmp 
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SYSCALL  SYSCALL Name ARG1 ARG2 ARG3 
313 sys_finit module 
314 Sys sched setattr 
315 Sys sched getattr 
316 sys renameat2 

317 sys_seccomp 

318 sys_getrandom 

319 sys_memfd_create 
320 sys_kexec_file_load 
321 sys_bpf 

322 stub_execveat 

323 userfaultfd 

324 membarrier 

325 mlock2 

326 copy_file_range 
327 preadv2 

328 pwritev2 

499 li_getaddrinfo 

500 li_getnameinfo 
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